Skip to content

CC-42186: Sanitize DLQ WriteException/WriteConcernException (drop document BSON details) - #114

Draft
Sharan Rudresh (sharanrudresh) wants to merge 1 commit into
v2.0.xfrom
user/sharan/CC-42186_sanitize-dlq-writeexception
Draft

CC-42186: Sanitize DLQ WriteException/WriteConcernException (drop document BSON details)#114
Sharan Rudresh (sharanrudresh) wants to merge 1 commit into
v2.0.xfrom
user/sharan/CC-42186_sanitize-dlq-writeexception

Conversation

@sharanrudresh

@sharanrudresh Sharan Rudresh (sharanrudresh) commented Jun 30, 2026

Copy link
Copy Markdown
Member

Summary

Sanitizes the two DLQ exception classes so that the failing document's BSON is no longer leaked:

  • WriteException
  • WriteConcernException

Both previously embedded error.getDetails().toJson() (the failing document's BSON) directly in getMessage(). This change drops the details field from both message formats and bumps the documented message-format version 1 → 2. The code / codeName / message fields are retained.

Why this is needed (the gap #110 left)

#110 deliberately scoped its fix to the ERROR log statements and explicitly left the DLQ exception classes untouched. As a result the document BSON still escaped via two paths that #110 did not close:

  1. DEBUG logsStartedMongoSinkTask.log() does LOGGER.debug("…(full detail)", records.size(), e), where e is the WriteException; its getMessage() (with details=<BSON>) prints in full at DEBUG.
  2. DLQ error headersAnalyzedBatchFailedWithBulkWriteException.report()errorReporter.report(record, writeException), so the exception message (with BSON) lands in the DLQ record's error headers.

Message-format version bump (reviewer note)

Removing the details field is a breaking change to the documented DLQ message contract, so MESSAGE_FORMAT_VERSION is bumped 1 → 2 and the javadoc updated — the v= marker exists precisely to signal this. Any downstream consumer parsing the v=1 format (with a trailing details=…) should key off the version.

Scope

  • Drops details only. The driver's message string is retained. Note: for duplicate-key errors the driver's message can itself echo the conflicting key value — sanitizing that further was considered and intentionally left out of scope for this PR.
  • Tests: StartedMongoSinkTaskTest references these classes by type (new Report(idx, WriteException.class)), not by message string, so no test changes were required. (Build/tests not run locally — relying on CI.)

Related

This is the follow-up flagged on the backport PR #113 (which cherry-picked #110 to v1.16.x). This PR targets v2.0.x; a matching v1.16.x change can follow if desired.

JIRA

  • CC-42185StartedMongoSinkTask logs full Mongo write-error documents at ERROR (fix rec: drop details.toJson() from WriteException.getMessage())
  • CC-42186AnalyzedBatchFailedWithBulkWriteException dispatches document BSON to the ERROR log (fix rec: strip BSON details from WriteException.getMessage())

Originating work: #110.

…ception

PR #110 sanitized the ERROR log statements but left the DLQ exception
classes untouched. WriteException / WriteConcernException still embedded
the failing document's BSON (error.getDetails().toJson()) in getMessage(),
which surfaces:
  - at DEBUG via StartedMongoSinkTask.log() (LOGGER.debug(..., e)), and
  - in DLQ error headers via AnalyzedBatchFailedWithBulkWriteException.report().

Drop the `details` field from both message formats and bump the documented
message-format version 1 -> 2 (the `v` marker exists precisely to signal
such format changes). code / codeName / message are retained.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant